SNSとSQSの簡単比較

SNSとSQSの比較

Amazon SNS

AWSホームページで説明しているSNSの概要です。

Amazon Simple Notification Service (Amazon SNS) は、アプリケーション対アプリケーション（A2A）間と、 アプリケーション対個人（A2P）間の両方の通信に使用できる、フルマネージド型メッセージングサービスです。

特徴

---

Amazon SNSの特徴について話します。

-「Publish - Subscribe(pub-sub)　パブリッシュ ー 購読メッセージングモデル」

• • 非同期サービス間通信の一つの形で、サーバレス及びマイクロサービスで使われます。
  • イベントベースのアーキテクチャやアプリケーションの間の依存性分離、性能や安定性を高めるために使用できます。

-「メッセージをシステムの他の部分に非同期的にブロードキャスト可能」

-「トピック(Topic)を生成して、トピックの所有者はメッセージを発行(Pub)したり購読対象の制限、アラームプロトコル指定などのポリシーの設定可能」

• • トピックは特定なタイトルまたはイベントを識別するアクセスところです。
  • 各トピックを購読した全ての購読者が受信します。(トピック所有者が制限可能)

-「購読者はこのアラームを受信」

• • 基本的に各購読者はトピックに掲示された全てのメッセージを受信します。

-「一つのメッセージを多数のサービスが処理可能」

-「多様なエンドポイント・プロトコルを使えます。」

• • SQS, Lmabda, HTTP(S), SMS, E-mail(JSON), Kinesis Data Firehoseなどのエンドポイント・プロトコルを使うことができます。

活用されるパタン

---

Fanout pattern 

FanoutパタンはFanoutシナリオ・アーキテクチャとも言えます。SNSのトピックに掲示されたメッセージが複数のエンドポイントでプッシュされるパタンです。並列非同期処理ができます。

代表的には複数のLambda関数を同時に呼び出す時に有用です。LmabdaだけではなくSQSやEC2など他のAWSサービスとの連携も勿論できます。

Amazon SQS

Amazon Simple Queue Service (SQS) は、フルマネージド型のメッセージキューイングサービスで、マイクロサービス、 分散システム、およびサーバーレスアプリケーションの切り離しとスケーリングが可能です。

特徴

---

-「ポーリングモデルを通じてメッセージを交換するメッセージキューサービス」

• • 非同期式サービス対サービス通信の一つの形で、サーバレス及びマイクロサービスで使われます。
  • 送信要素と受信要素を分離できます。

-「メッセージを保存可能」

• • 最大14日までめっせーじを保存できます。
  • メッセージは処理・削除されるまでキューに保存されます。

-「消費者がキューからメッセージを受信・処理してもメッセージはキューに存在」

• • SQSはメッセージを自動に削除しません。
  • 消費者は処理が完了になったメッセージをキューから削除する必要があります。

-「一つのメッセージは一回だけ処理」

活用されるパタン

---

Messaging patternやルーズカップリング

Messaging patternは 1 対 1 通信、またはポイント対ポイント通信とも言えます。1 対 1という言葉を通じて分かるように各メッセージは一つの消費者によって一回だけ処理されます。

サービスや機能の間に依存性を分離させ、拡張性と安定性が高いシステムを構築できます。メッセージを処理するサービスがオフになってもメッセージはキューに保存されていますので後に処理できます。

ルーズカップリングまたはデカップリングと言えます。サービスの間の依存性減らして、高い柔軟性・安定性を実装できます。上の絵のように、LambdaはEC2インスタント直接に連結せずにSQSを経てEC2に届く形になっています。LambdaはただSQSにタスクを送り、EC2インスタンスはSQSの中のメッセージを処理するだけです。つまり、LambdaとEC2インスタンスはメッセージがどこへ行くのかどこから来るのか考える必要がないです。

最後に

今まで簡単にAmazon SNSとSQSを調べてみました。まだSNSとSQSについてはもっとありますが、詳しい話よりも二つの比較が重要ですので抜きました。そしてAmazon SNSとSQSは別のサービスですが、お互いの連携を通じてマイクロサービスやサーバーレスアーキテクチャの実装ができますので、必ず一つのサービスだけではなく多様なサービスと連携しながら豊かな構築をしてみることもいいと思います。

参照

Pub/Sub Messaging

メッセージキュー

Patterns for Solving Problems in Serverless Architectures